7.2.0 release documentation by Chr1st0ph3rTurn3r · Pull Request #1014 · 128technology/docs

Chr1st0ph3rTurn3r · 2026-05-12T18:54:09Z

No description provided.

tjbresnahan · 2026-05-13T17:11:53Z

+SSR 7.2.0 introduces two complementary enhancements to address these gaps:
+
+1. **Underlay ICMP reaction** — When the SSR receives a TooBig packet from the underlay, it updates the affected overlay flow and generates a corrected TooBig packet toward the original packet sender, allowing the sender to adjust its segment size.
+2. **PMTUD-triggered session refresh** — When a periodic PMTUD cycle discovers a new path MTU, existing sessions that are eligible for flow-move are refreshed to use the new value on the next packet.


This is not being delivered in 7.2.0

tjbresnahan · 2026-05-13T17:15:54Z

+    Note over R2,R1: Underlay MTU between Hub and R2 drops to 1300
+    Hub->>R2: SVR packet hub-WAN to spoke-WAN (over 1300 bytes)
+    R2-->>Hub: ICMP TooBig type 3 code 4, reported MTU = 1300
+    Note over Hub: DivertedPacketHandler finds reverse flow. Updates Hub-to-Spoke PMTU to 1300.


We should emphasis that this only affects this particular flow. A different session using this same path does not realize the PMTU reported to this session. It also does not persist, meaning if the session is modified for some other reason (FIB update, device flap, etc), the egress MTU is 'reset' back to the latest at that time based on the most recent BFD-based PMTU detection test, or interface MTU if no such test has been done

tjbresnahan · 2026-05-13T17:17:11Z

+    Note over Server: Server adjusts MSS if TCP-capable
+```
+
+When R2 (an underlay device) cannot forward an oversized packet, it sends a TooBig packet to the Hub's WAN interface. The SSR's `DivertedPacketHandler` processes this message:


Should we call out DivertedPacketHandler in these docs? It feels like it crosses into implementation details. I guess it depends on how we callout individual processes elsewhere in documentation

tjbresnahan · 2026-05-13T17:18:07Z

+When R2 (an underlay device) cannot forward an oversized packet, it sends a TooBig packet to the Hub's WAN interface. The SSR's `DivertedPacketHandler` processes this message:
+
+1. It extracts the encapsulated IP header from the TooBig body to identify the affected overlay session.
+2. It finds the reverse flow using that header and updates the Hub → Spoke forward flow's PMTU to the value reported by the underlay.


Pedantic, but it doesnt have to be a reverse flow. It's whatever flow was traversed to elicit the TooBig response. In the context of a TCP download used throughout this doc, it would likely be a reverse flow

tjbresnahan · 2026-05-13T17:19:49Z

+3. It constructs a new TooBig packet directed toward the original packet sender (the Server), so the server's TCP stack can reduce its MSS.
+
+:::note
+The MTU value propagated in the new TooBig packet reflects the underlay-reported value. On paths with encryption, HMAC, FEC, or BFD tunneling overhead, the effective usable MTU will be lower than the raw underlay value. The SSR accounts for these overheads when setting the MSS on forward flow actions.


MTU, not MSS

... when setting the egress MTU on forward flow actions.

tjbresnahan · 2026-05-13T17:22:05Z

+
+## Fabric Fragmentation and Oversize Packet Behavior
+
+When the PMTU on an overlay (SVR/fabric) path is lower than the MTU of the segment immediately preceding the Hub, packets larger than the PMTU will require fragmentation along the overlay. The SSR always fragments fabric packets when necessary, even when the incoming packet carries the Don't Fragment (DF) bit. This preserves packet delivery but prevents the sender from learning about the smaller path MTU and adjusting its segment size.


IPv6 traffic also is supposed to never fragment at a router, but like the IPv4 with dont-frag, we do anyways when its an SVR path

tjbresnahan · 2026-05-13T17:23:31Z

+When the PMTU on an overlay (SVR/fabric) path is lower than the MTU of the segment immediately preceding the Hub, packets larger than the PMTU will require fragmentation along the overlay. The SSR always fragments fabric packets when necessary, even when the incoming packet carries the Don't Fragment (DF) bit. This preserves packet delivery but prevents the sender from learning about the smaller path MTU and adjusting its segment size.
+
+:::note
+For TCP traffic, setting `enforced-mss automatic` on the egress `network-interface` is the most reliable way to avoid this scenario. When set, the SSR rewrites the TCP MSS at the interface boundary to match the session MTU (including the path MTU for SVR sessions). This is not the default and must be explicitly configured.


This process is more widely known as MSS Clamping. We should sprinkle that in here. Also, the SSR will further reduce the MSS based on any overhead needed by the SSR, as mentioned earlier in the doc (thats the actual clamping)

tjbresnahan · 2026-05-13T17:25:22Z

+For TCP traffic, setting `enforced-mss automatic` on the egress `network-interface` is the most reliable way to avoid this scenario. When set, the SSR rewrites the TCP MSS at the interface boundary to match the session MTU (including the path MTU for SVR sessions). This is not the default and must be explicitly configured.
+:::
+
+### Oversize Fabric Packet Behavior


None of this section has been implemented for 7.2.0

tjbresnahan · 2026-05-13T17:25:53Z

+Packets that do not carry the DF bit fragment immediately regardless of this setting. Only packets that would otherwise be fragmented on an SVR path are subject to this behavior.
+:::
+
+#### Configuration Location


Same, this config knob doesnt exist

tjbresnahan · 2026-05-13T17:26:27Z

+exit
+```
+
+### Enabling Session Refresh on PMTU Change


This functionality is not in 7.2.0

tjbresnahan · 2026-05-13T17:29:43Z

+
+## Verification
+
+Use `show peers` to confirm the currently discovered path MTU for each peer path:


Nothing to correct here, just clarifying that this IS correct today. The show peers command investigates the peer path, which will show the PMTU at that moment in time. It's the session level part that only updates when a TooBig packet comes in, and only for that single session.

I dont think there's visibility into that from a show command perspective.

A new stat, stats/icmp/flow-mtu-updates, is a count of flows that have had their MTU updated at runtime via a TooBig packet. This counter is reset when the system resets (not persisted)

tjbresnahan · 2026-05-13T17:30:46Z

+
+- If the path MTU shown by `show peers` does not reflect the expected value, verify that `path-mtu-discovery > enabled` is `true` on both sides of the adjacency.
+- If TCP sessions continue to fragment after configuring `enforced-mss automatic`, confirm the setting is applied to the correct egress interface and that both peers have completed a PMTUD cycle.
+- If existing sessions are not picking up a new PMTU after a PMTUD cycle, verify the `service-policy` for those sessions has `session-resiliency` set to `failover` or `revertible-failover`.


This is not a useful check today

tjbresnahan · 2026-05-13T17:33:35Z

+SSR 7.2.0 introduces two complementary enhancements to address these gaps:
+
+1. **Underlay ICMP reaction** — When the SSR receives a TooBig packet from the underlay, it updates the affected overlay flow and generates a corrected TooBig packet toward the original packet sender, allowing the sender to adjust its segment size.
+2. **PMTUD-triggered session refresh** — When a periodic PMTUD cycle discovers a new path MTU, existing sessions that are eligible for flow-move are refreshed to use the new value on the next packet.


The two deliveries related to MTU are

The MTU in the TooBig packet is corrected by reducing the amount of overhead needed by the SSR

The flow which was traversed to trigger the TooBig response from the underlay is now updated to use the MTU reported in the TooBig packet

…hether changes are needed, and need to get stats example.

dmontgomeryJuniper · 2026-05-14T12:33:53Z

+
+### Configuring AES-GCM
+
+AES-GCM is selected by setting the `encryption-cipher` field of a security policy to the appropriate AES-GCM value. The security policy is then applied in the same locations as any other cipher:


Add a mention that new selectable values are aes-gcm-128 and aes-gcm-256

dmontgomeryJuniper · 2026-05-14T12:35:58Z

+
+### Verifying AES-GCM Is In Use
+
+After applying the new policy, use `show sessions by-id` to confirm the cipher is active on new sessions. The **Payload Security Policy** and **Metadata Security Policy** fields identify which security policy is applied per flow. Confirm that the policy you configured with AES-GCM is listed for the expected flows.


The Action List fields will also include GCM encryption/decryption actions: AesGcmEncrypt, AesGcmDecrypt, AesGcmEncryptSvr2, AesGcmDecryptSvr2

dmontgomeryJuniper

Couple of suggestions

MichaelBaj · 2026-05-14T19:01:00Z

+  onBrokenMarkdownLinks: 'throw',
  markdown: {
    mermaid: true,
-    hooks: {


Not sure why this change was made.

https://docusaurus.io/docs/api/docusaurus-config#onBrokenMarkdownLinks

Was existed previously is the new way to handle markdown reference handling

MichaelBaj · 2026-05-14T19:23:00Z

+
+```text
+admin@router1.site1# show bgp neighbors 172.16.3.3 filtered-routes
+```


Please provide at least a CLI output for IPv4

MichaelBaj · 2026-05-14T19:30:35Z

@@ -0,0 +1,209 @@
+---
+title: Path MTU Discovery Enhancements


Since there does not exist a document for Path MTU for the SSR, I would suggest calling this document Path MTU Discover, and leave off the Enhancements. We should use this document to describe overall PMTU behavior, including the enhancements.

The only area in our docs that covers PMTU is concepts_machine_communication.

I would leave that content there, but provide a link to this new document. It might be worthwhile to duplicate some or all of the other content here.

MichaelBaj · 2026-05-14T19:31:38Z

+
+| Release | Modification |
+| ------- | ------------ |
+| 7.2.0   | Feature introduced |


Untrue. PMTU has been around for a long time. Perhaps from the beginning? Might be better off removing this version history table.

MichaelBaj · 2026-05-14T19:41:37Z

+            node  <node-name>
+                device-interface  <device-interface-name>
+                    network-interface  <network-interface-name>
+                        oversize-fabric-packet-behavior  true


is oversize-fabric-packet-behavior true a new configuration attribute? What is the default?

MichaelBaj · 2026-05-14T19:46:33Z

+| Integrity | Authenticated; authentication failure causes immediate packet discard. |
+| HMAC settings | Ignored when AES-GCM is selected — authentication is inherent to GCM. |
+| Peer compatibility | If the remote peer does not support AES-GCM, the session falls back to the mutually supported cipher according to existing SSR negotiation behavior. |
+| Mixed-version fabrics | Supported, provided peers negotiate a mutually supported cipher. |


Same as above...

MichaelBaj · 2026-05-14T19:47:13Z

+| HMAC settings | Ignored when AES-GCM is selected — authentication is inherent to GCM. |
+| Peer compatibility | If the remote peer does not support AES-GCM, the session falls back to the mutually supported cipher according to existing SSR negotiation behavior. |
+| Mixed-version fabrics | Supported, provided peers negotiate a mutually supported cipher. |
+| Platform requirement | Requires OpenSSL with GCM capability; supported on existing SSR hardware platforms. |


I would remove this line. Of course the SSR is interoperating with other SSRs. Peers need to be on 7.2+

MichaelBaj · 2026-05-14T19:51:47Z

+:::
+
+:::caution
+Changing an encryption cipher is a service-impacting event. Existing sessions cannot be re-keyed in-place. Follow the guidance in [Changing A Security Policy](#changing-a-security-policy) and perform the change during a maintenance window.


What does happen when a security policy is changed on a running system? Will new session use the new security-policy setting while existing sessions will remain on the old configuration? Or do all sessions get updated (i.e., pre-existing sessions will be destroyed and recreated as new sessions)?

MichaelBaj · 2026-05-14T19:53:16Z

+
+### Verifying AES-GCM Is In Use
+
+After applying the new policy, use `show sessions by-id` to confirm the cipher is active on new sessions. The **Payload Security Policy** and **Metadata Security Policy** fields identify which security policy is applied per flow. The **Action List** fields include the GCM encryption and `decryption actions: `AesGcmEncrypt`, `AesGcmDecrypt`, `AesGcmEncryptSvr2`, and `AesGcmDecryptSvr2. Confirm that the policy you configured with AES-GCM is listed for the expected flows.


What is AesGcmDecryptSvr2? I see AesGcmEncryptMetadata in the output below. I'd like to think we didn't put "Svrv2" in CLI output.

MichaelBaj · 2026-05-14T19:54:22Z

+     Bytes Sent:                    151464
+     Tcp Retransmission Count:      N/A
+     Decrypt Security Policy:       <empty>
+     Action List:                    Ingress TtlValidateIpv4 IpHeaderTransform AesGcmEncrypt AppMetadataAdd AesGcmEncryptMetadata EthernetHeaderTransform AppForward


@dmontgomeryJuniper as per this doc set, is there detailed session output that displays per-session MTU values?

Chr1st0ph3rTurn3r added 2 commits May 11, 2026 16:18

adding documentation for show bgp output I95-61467

7912820

adding AES-GCM content for 7.2 Swift beta 1.

fda9957

Chr1st0ph3rTurn3r requested a review from dmontgomeryJuniper May 12, 2026 18:54

Chr1st0ph3rTurn3r requested a review from MichaelBaj as a code owner May 12, 2026 18:54

Chr1st0ph3rTurn3r requested a review from aayan-AIDE May 12, 2026 20:30

Merge branch 'master' into 7.2.0-release-documentation

e56e3cb

aayan-AIDE previously approved these changes May 12, 2026

View reviewed changes

adding pmtu topic for 7.2

76d864c

Chr1st0ph3rTurn3r dismissed aayan-AIDE’s stale review via 76d864c May 13, 2026 16:16

Chr1st0ph3rTurn3r requested a review from tjbresnahan May 13, 2026 16:20

tjbresnahan reviewed May 13, 2026

View reviewed changes

most of TJ's comments. Need the graphics to display so I can verify w…

94e4ffc

…hether changes are needed, and need to get stats example.

dmontgomeryJuniper reviewed May 14, 2026

View reviewed changes

Updates per Dennis' comments

bf3af36

MichaelBaj requested changes May 14, 2026

View reviewed changes


		## Fabric Fragmentation and Oversize Packet Behavior

		When the PMTU on an overlay (SVR/fabric) path is lower than the MTU of the segment immediately preceding the Hub, packets larger than the PMTU will require fragmentation along the overlay. The SSR always fragments fabric packets when necessary, even when the incoming packet carries the Don't Fragment (DF) bit. This preserves packet delivery but prevents the sender from learning about the smaller path MTU and adjusting its segment size.


		## Verification

		Use `show peers` to confirm the currently discovered path MTU for each peer path:


		### Configuring AES-GCM

		AES-GCM is selected by setting the `encryption-cipher` field of a security policy to the appropriate AES-GCM value. The security policy is then applied in the same locations as any other cipher:


		### Verifying AES-GCM Is In Use

		After applying the new policy, use `show sessions by-id` to confirm the cipher is active on new sessions. The Payload Security Policy and Metadata Security Policy fields identify which security policy is applied per flow. Confirm that the policy you configured with AES-GCM is listed for the expected flows.

Conversation

Chr1st0ph3rTurn3r commented May 12, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tjbresnahan May 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tjbresnahan May 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dmontgomeryJuniper left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

tjbresnahan May 13, 2026 •

edited

Loading

tjbresnahan May 13, 2026 •

edited

Loading